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TOWARDS  A  METRICS  SUITE  FOR  OBJECT  ORIENTED  DESIGN 


Abstract 

This  paper  presents  theoretical  woric  that  builds  a  suite  of  metrics  for  object-oriented  design. 
In  particular,  these  metrics  are  based  upon  measurement  theory  and  are  also  informed  by  the 
insights  of  experienced  object-oriented  software  developers.  In  evaluating  these  metrics 
against  a  standard  set  of  criteria,  they  are  found  to  both  (a)  perform  relatively  well,  and  (b) 
suggest  some  ways  in  which  Lhe  object  oriented  approach  may  differ  in  terms  of  desirable  or 
necessary  design  features  from  more  traditional  approaches. 

In  order  for  object-oriented  software  production  to  fulfill  its  promise  in  moving  software 
development  and  maintenance  from  the  current  'craft'  environment  into  something  more 
closely  resembling  conventional  engineering,  it  will  require  metrics  of  the  process  to  aid  the 
software  management,  project  planning  and  project  evaluation  functions.  While  software 
metrics  are  a  generally  desirable  feature  in  any  software  environment,  they  are  of  special 
imponance  in  the  object-oriented  approach,  since  it  represents  a  non-trivial  technological 
change  for  the  organization. 

The  metrics  presented  in  this  paper  are  the  first  steps  in  a  project  aimed  at  measuring  and 
evaluating  the  use  of  object  oriented  design  principles  in  organizations. 


Accepted  for  publication  in  the  sixth  annual  ACM  conference  on  Object  Oriented  Programming,  Systems, 
Languages  and  Applications  (OOPSLA),  October  1991. 


I.  INTRODUCTION 

In  order  for  objea-oriented  sofrware  production  to  fulfill  its  promise  in  moving  software 
development  and  maintenance  from  the  current  'craft'  environment  into  something  more  closely 
resembling  conventional  engineering,  it  will  require  measures  or  metrics  of  the  process.  While 
software  metrics  are  a  generally  desirable  feanire  in  the  software  management  functions  of  project 
planning  and  project  evaluation,  they  are  of  special  importance  with  a  new  technology  such  as  the 
object-oriented  approach. 

This  is  due  to  the  significant  need  to  train  current  and  new  software  engineers  in  generally  accepted 
object-oriented  principles.  This  paper  presents  theoretical  work  that  builds  a  suite  of  metrics  for 
object-oriented  design  (OOD).  In  particular,  these  metrics  are  based  upon  measurement  theory  and 
are  informed  by  the  insights  of  experienced  object-oriented  software  developers.  The  proposed 
metrics  are  evaluated  against  a  widely-accepted  list  of  seven  software  metric  evaluation  criteria,  and 
the  formal  results  of  this  evaluation  are  presented. 

Development  and  validation  of  software  metrics  is  expected  to  provide  a  number  of  practical 
benefits.  In  general,  techniques  that  provide  measures  of  the  size  and  of  the  complexity  of  a 
software  system  can  be  used  to  aid  management  in: 

-  estimating  the  cost  and  schedule  of  future  projects, 

-  evaluating  the  productivity  impacts  of  new  tools  and  techniques, 

-  establishing  productivity  trends  over  time, 

-  improving  software  quality, 

-  forecasting  future  staffing  needs,  and 

-  anticipating  and  reducing  future  maintenance  requirements. 

More  specifically,  given  the  relative  newness  of  the  00  approach,  metrics  oriented  towards  00  can 
aid  in  evaluating  the  degree  of  object  orientation  of  an  implementation  as  a  learning  tool  for  staff 
members  who  are  new  to  the  approach.  In  addition,  they  may  also  eventually  be  useful  objective 
criteria  in  setting  design  standards  for  an  organization. 

This  paper  is  organized  as  follows.  Section  n  presents  a  very  brief  summary  of  the  need  for 
research  in  this  area.  Section  EQ  describes  the  theory  underlying  the  approach  taken.  Section  IV 
presents  the  proposed  metrics,  and  Section  V  presents  Weyuker's  list  of  software  metric  evaluation 
criteria  [Weyuker,  1988].  Section  VI  contains  the  results  of  the  evaluation  of  the  proposed 
metrics,  and  some  concluding  remarks  are  presented  in  Section  VIL 


II.  RESEARCH  PROBLEM 

There  are  two  types  of  criticisms  that  can  be  applied  to  current  software  metrics.  The  first  category 
are  those  criticisms  that  are  leveled  at  conventional  software  metrics  as  they  are  applied  to 
conventional,  non-00  software  design  and  development.  These  metrics  are  generally  criticized  as 
being  without  solid  theoretical  bases ^  and  failing  to  display  what  might  be  termed  normal 
predictable  behavior  [Weyuker,  1988]. 

The  second  category  is  more  specific  to  00  design  and  development.  The  00  approach  centers 
around  modeling  the  real  world  in  terms  of  its  objects,  which  is  in  stark  contrast  to  older,  more 
traditional  approaches  that  emphasize  a  function-oriented  view  that  separated  data  and  procedures. 
Given  the  fundamentally  different  notions  inherent  in  these  two  views,  it  is  not  surprising  to  find 
that  software  metrics  developed  with  traditional  methods  in  inind  do  not  readily  lend  themselves  to 
notions  such  as  classes,  inheritance,  encapsulation  and  message  passing.  Therefore,  given  that 
current  software  metrics  are  subject  to  some  general  criticism  and  are  easily  seen  as  not  supporting 
key  GO  concepts,  it  seems  appropriate  to  develop  a  set,  or  suite  of  new  metrics  especially  designed 
to  measure  unique  aspects  of  the  00  approach. 

Some  early  work  has  recognized  the  shortcomings  of  existing  metrics  and  the  need  for  new  metrics 
especially  designed  for  00.  Some  proposals  are  set  out  by  Morris,  although  they  are  empirically 
suggested  rather  than  theoretically  driven  [1988].  Pfleeger  also  suggests  the  need  for  new 
measures,  and  uses  counts  of  objects  and  methods  to  develop  and  test  a  cost  estimation  model  for 
OO  development  [Pfleeger,  1989;  Pfleeger  and  Palmer,  1990].  Moreau  and  Dominick  suggest 
three  metrics  for  00  graphical  information  systems,  but  do  not  provide  formal,  testable  definitions 
[1989].  In  contrast,  Lieberherr  and  his  colleagues  present  a  well-articiilated,  formal  approach  in 
documenting  the  Law  of  Demeter™  [1988]  The  Demeter  system  represents  a  formal  attempt  at 
defining  the  rules  of  correct  object  oriented  programming  style,  building  on  concepts  of  coupling 
and  cohesion  that  are  used  in  traditional  programming. 

Given  the  extant  software  metrics  literature,  the  approach  taken  here  is  to  develop  theoretically- 
driven  metrics  that  can  be  shown  to  offer  desirable  properties,  and  then  choose  the  most  promising 
candidates  for  future  empirical  study.  This  paper  is  an  initial  presentation  of  six  candidate  metrics 
specifically  developed  for  measuring  elements  contributing  to  the  size  and  complexity  of  object- 
oriented  design.  Since  object  design  is  considered  to  be  a  unique  aspect  of  OOD,  the  proposed 
metrics  directly  address  this  task.  The  metrics  are  constructed  with  a  firm  basis  in  theoretical 
concepts  in  measurement,  while  capturing  empirical  notions  of  software  complexity. 


'For  example,  see  [Vessey  and  Weber,  1984]  and  [Kearney,  et  al.,  1986]. 


III.  THEORY  BASED  METRICS  FOR  OOD 

Booch  (1986)  defines  object  oriented  design  to  be  the  process  of  identifying  objects  and  their 
attributes,  identifying  operations  required  on  each  object  and  establishing  interfaces  between 
objects.  Design  of  classes  involves  three  steps:  1)  definition  of  objects,  2)  attributes  of  objects  and 
3)  communication  between  objects.  Methods  design  involves  defining  procedures  which 
implement  the  attributes  and  operations  suffered  by  objects.  Class  design  is  therefore  at  a  higher 
level  of  abstraction  than  the  traditional  data/procedures  approach  (which  is  closer  to  methods 
design).  It  is  the  task  of  class  design  that  makes  OOD  different  than  data/procedure  design  [Taylor 
&  Hechi,  1990].  The  reader  is  referred  to  works  by  Deutsch,  et  al.  [1983],  Meyer  [1988],  Page, 
et  al.  [1989],  Pamas,  et  al.  [1986],  Seidewitz  and  Stark  [1986]  and  others  for  an  introduction  to 
the  fundamental  concepts  and  terminology  of  object-oriented  design. 


Figure  1  shows  the  fundamental  elements  of  object  oriented  design  as  outlined  by  Booch  [1986]. 


(jDmmunication 
Among  Objects 


Rgurcl:  Elements  ofObject  Oriented  Design 


Measurement  theory  base 

A  design  can  be  viewed  as  a  relational  system,  consisting  of  object  elements,  empirical  relations 
and  binary  operations  that  can  be  performed  on  the  object  elements. 


Notationally:  design  P  =  (A,  Rj...  Rn,0i...0in) 

where 

A  is  a  set  of  object  elements 

Rl...Rn  are  empirical  relations  on  object  elements  A  (e.g,  bigger  than,  smaller  than,  etc) 


Oi...Oryi  are  binary  operanons  (e.g.,  concatenation) 

A  useful  way  to  conceptualize  empirical  relations  on  a  set  of  object  elements  in  this  context  is  to 
consider  the  measurement  of  complexity.  A  designer  has  ideas  about  the  complexity  of  different 
objects,  as  to  which  object  is  more  complex  than  another.  This  idea  is  defined  as  a  viewpoint.  The 
notion  of  a  viewT^oint  was  originally  introduced  to  describe  evaluation  measures  for  information 
retrieval  systems  and  is  applied  here  to  capture  designer  views  [Chemiavsky,  1971].  An  empirical 
relation  is  the  embodiment  of  a  viewpoint. 

A  viewpoint  is  a  binary  relation  .>  defined  on  the  set  P.  For  P,  P',  P"  e  set  P  ,  the  following 
axioms  must  hold: 

P  .>  P  (reflexivity) 

P  .>  P  or  P  .>  P  (completeness) 

P.>  P',  P'.>  P"  =>  P.>  P"       (transitivity) 

i.e.,  a  viewpoint  must  be  of  weak  order  [Zuse,  1987]. 

To  be  able  to  measure  something  about  a  object  design,  the  empirical  relational  system  as  defined 
above  needs  to  be  transformed  to  di  formal  relational  system  [Roberts,  1979].  Therefore,  let  a 
formal  relational  system  Q  be  defined  as  follows: 


Qh  (C,  Si...  Sn,  h\...  bm) 

C  is  a  set  of  elements  (e.g.,  real  numbers) 

S\...  Sn  ^XQ  formal  relations  on  C  (e.g.,  >,  <,  =) 

b\...  bjn  are  binary  operations  (e.g.,  +,-,*) 


This  is  accomplished  by  a  metric  \i  which  maps  an  empirical  system  P  to  a  formal  system  Q.  For 
every  element  a  €  P,  |i(a)  e  Q. 

Definitions 

The  ontological  basis  principles  proposed  by  Bunge  in  his  "Treatise  on  Basic  Philosophy"  forms 
the  basis  of  the  concept  of  objects  [Bunge,  1977].  Consistent  with  this  ontology,  objects  are 
defined  independent  of  implementation  considerations  and  encompass  the  notions  of  encapsulation, 
independence  and  inheritance.  According  to  this  ontology,  the  world  is  viewed  as  composed  of 
things,  referred  to  as  substantial  individuals  ,and  concepts.  The  key  notion  is  that  substantial 


individuals  possess  properues.  A  properly  is  a  feature  that  a  substantial  individual  possesses 
inherently.  An  observer  can  assign  features  to  an  individual,  these  are  attributes  and  not 
properties.  All  substantial  individuals  possess  a  finite  set  of  properties.  "There  are  no  bare 
individuals  except  in  our  imagination"  [Bunge,  1979]. 

Some  of  the  attributes  of  an  individual  will  reflect  its  properties.  Indeed,  properties  are  recognized 
only  through  attributes.  A  known  property  must  have  at  least  one  attribute  representing  it. 
Propenies  do  not  exist  on  their  own  but  are  "attached"  to  individuals.  On  the  other  hand, 
individuals  are  not  bundles  of  properties.  A  substantial  individual  and  its  properties  collectively 
constitute  an  object  [Wand,  1987;  Wand  and  Weber,  1990]. 

An  object  can  be  represented  in  the  following  manner 

X  =  <x,  p(x)>  where  x  is  the  substantial  individual  and  p(x)  is  the  finite  collection  of  its  properties. 

X  can  be  considered  to  be  the  token  or  name  by  which  the  individual  is  represented  in  a  system.  In 
object  oriented  terminology,  the  instance  variables  together  with  its  methods  are  the  properties  of 
the  object  [Baneijee,  et  al.,  1987]. 

Coupling 

Two  things  are  coupled  if  and  only  if  at  least  one  of  them  "acts  upon"  the  other  [Wand,  1990].  X 
is  said  to  act  upon  Y  if  the  history  of  Y  is  affected  by  X,  where  history  is  defined  as  the 
chronologically  ordered  states  that  a  thing  traverses  in  time. 

let  X  =  <x,  p(x)>  and  Y  =  <y,  p(y)>  be  two  objects. 

p(x)  =  {  Sx  }  u  {  Ix  } 
P(y)  =  {  Sy  )  u  {  ly  ) 

where  {  Si  )  is  the  set  of  methods  and  {  Ij  )  is  the  set  of  instance  variables  of  object  /. 
Using  the  above  defmition  of  coupling,  any  action  by  (Sx)  on  (Sy)  or  {ly)  constitutes 
coupling,  as  does  any  action  by  {Sy }  on  (Sx)  or  (ly).  Therefore,  any  evidence  of  a  method  of 
one  object  using  methods  or  instance  variables  of  another  object  constitutes  coupling.  This  is 
consistent  with  the  law  of  Demeter™  [Lieberherr,  et  al.,  1988].  In  order  to  promote  encapsulation 
of  objects  it  is  generally  considered  good  practice  to  reduce  coupling  between  objects. 


Cohesion 

Bunge  [1977]  defines  similarity  o()  of  two  objects  to  be  the  intersection  of  tfie  sets  of  properties  of 

the  two  objects: 
a(X,Y)  =  p(x)  n  p(y) 

Following  this  general  principle  of  defining  similarity  in  terms  of  sets,  the  degree  of  similarity  of 
the  methods  within  the  object  can  be  defined  to  be  the  intersection  of  the  sets  of  instance  variables 
that  are  used  by  the  methods.  It  should  be  clearly  understood  that  instance  variables,  are  not 
properties  of  methods,  but  it  makes  intuitive  sense  that  methods  that  operate  on  the  same  instance 
variables  have  some  degree  of  similarity. 

o(Mi,M2...Mn)  =  {  Mj  )  n  (  M2  )  n  {  M3  )  ...  {  Mn  ) 

where  a()  =  degree  of  similarity  and  {  Mj  }  =  set  of  instance  variables  used  by  method  Mi. 

The  degree  of  similarity  of  methods  relates  both  to  the  conventional  notion  of  cohesion  in  software 
engineering,  (i.e.,  keeping  related  things  together)  as  well  as  encapsulation  of  objects,  that  is,  the 
bimdling  of  methods  and  instance  variables  in  an  object.  Cohesion  of  methods  can  be  defmed  to 
be  the  degree  of  similarity  of  methods.  The  higher  the  degree  of  similarity  of  methods,  the  greater 
the  cohesiveness  of  the  methods  and  the  higher  the  degree  of  encapsulation  of  the  object 

Complexiry  of  an  object 

Bunge  defmes  complexity  of  an  individual  to  be  the  "numerosity  of  its  composition",  implying  that 
a  complex  individual  has  a  large  number  of  propenies.  Using  this  definition  as  a  base,  the 
complexity  of  an  object  can  be  defined  to  be  the  cardinality  of  its  set  of  properties. 

Complexity  of  <x,  p(x)>  =  I  p(x)  I,  where  I  p(x)  I  is  the  cardinality  of  p(x). 

Scope  of  Properties 

The  scope  of  a  property  P  in  J  (  a  set  of  objects)  is  the  subset  G  (P;  J)  of  objects  possessing  the 

property. 

G(P;  J)  ={  X  I  X  €  J  and  P  e  p(x)  ) ,  where  p(x)  is  the  set  of  all  properties  of  all  x  €  J. 


Wand  defines  a  class  on  the  basis  of  the  nouon  of  scope  [1987],  A  class  P  with  respect  to  a 
propeny  set  p  is  the  set  of  all  objects  possessing  all  properties  in  p. 

C(p;  J)  =  n  all  p  {  G(P)  I  P  e  p(x)  ) 

The  inheritance  hierarchy  is  a  tree  structure  with  classes  as  nodes,  leaves  and  a  root.  Two  useful 
concepts  which  relate  to  the  inheritance  hierarchy  can  be  defined.  They  are  depth  of  inheritance  of 
a  class  and  the  number  of  children  of  a  class. 

Depth  of  Inheritance  =  height  of  the  class  in  the  inheritance  tree 

The  height  of  a  node  of  a  tree  refers  to  the  length  of  the  longest  path  from  the  node  to  the  root  of 
the  tree. 

Number  of  Children  =  Number  of  immediate  descendents  of  the  class 

Both  these  concepts  relate  to  the  notion  of  scope  of  properties,  i.e.,  how  far  does  the  influence  of 
a  property  extend?  The  number  of  children  and  depth  of  inheritance  collectively  indiCc^e  the 
genealogy  of  a  class.  Depth  of  inheritance  indicates  the  extent  to  which  the  class  is  influenced  by 
the  properties  of  its  ancestors  and  number  of  children  indicates  the  potential  impact  on  descendents. 

Methods  as  measures  of  communication 

In  the  object  oriented  approach,  objects  can  communicate  only  through  message  passing.  A 
message  can  cause  an  object  to  "behave"  in  a  particular  manner  by  invoking  a  particular  method. 
Methods  can  be  viewed  as  definitions  of  responses  to  possible  messages  [Baneijee,  et  al.,  1987]. 
It  is  reasonable  therefore  to  define  a  response  set  for  an  object  in  the  following  manner 

Response  set  of  an  object  =  { set  of  all  methods  that  can  be  invoked  in  response  to  a  message  to  the 
object} 

Note  that  this  set  will  include  methods  outside  the  object  as  well,  since  methods  within  the  object 
may  call  methods  from  other  objects.  The  response  set  will  be  fmite,  since  the  properties  of  an 
object  are  finite  and  there  are  a  finite  number  of  objects  in  a  design. 


IV.  THE  CANDIDATE  METRICS 

The  candidate  metrics  outlined  in  this  section  were  developed  over  a  period  of  several  months. 
This  was  done  in  conjunction  with  a  team  of  software  engineers  in  an  organization  which  has  used 
OOD  in  a  number  of  different  projects  over  the  past  four  years.  Though  the  primary  development 
language  for  all  projects  at  this  site  was  C+4-,  the  aim  was  to  propose  metrics  that  are  not  language 
specific.  The  viewpoints  presented  under  each  metric  reflea  the  object  oriented  design  experiences 
of  many  of  the  engineers,  and  are  presented  here  to  convey  the  intuition  behind  each  of  the  metrics. 

Metric  1:  Weighted  Methods  Per  Class  (WMC) 

Definition: 

Consider  a  Class  Ci,  with  methods  Mi,...  Mn.   Let  ci,...  Cn  be  the  static  complexity  of  the 

methods.  Then 

n 

WMC  =  X  Ci. 

i=l 

If  all  static  complexities  are  considered  to  be  unity,  WMC  =  n,  the  number  of  methods. 

Theoretical  basis: 

WMC  relates  directiy  to  the  definition  of  complexity  of  an  object,  since  methods  are  properties  of 
objects  and  complexity  of  an  object  is  determined  by  the  cardinality  of  its  set  of  properties.  The 
number  of  methods  is,  therefore,  a  measure  of  object  definition  as  well  as  being  attributes  of  an 
object,  since  attributes  correspond  to  properties. 

Viewpoints: 

The  number  of  methods  and  the  complexity  of  methods  involved  is  an  indicator  of  how  much  time 

and  effon  is  required  to  develop  and  maintain  the  object 

The  larger  the  number  of  methods  in  an  object,  the  greater  the  potential  impact  on  children,  since 
children  will  inherit  all  the  methods  defined  in  the  object 

Objects  with  large  numbers  of  methods  are  likely  to  be  more  application  specific,  limiting  the 
possibility  of  reuse. 


Metric  2:  Depth  of  Inheritance  Tree  (DIT) 

Definition: 

Depth  of  inheritance  of  the  class  is  the  DIT  metric  for  the  class. 

Theoretical  basis: 

DIT  relates  to  the  notion  of  scope  of  properties.  DIT  is  a  measure  of  how  many  ancestor  classes 

can  potentially  affect  this  class. 

Viewpoints: 

The  deeper  a  class  is  in  the  hierarchy,  the  greater  the  number  of  methods  it  is  likely  to  inherit, 

making  it  more  complex. 

Deeper  trees  constitute  greater  design  complexity,  since  more  methods  and  classes  are  involved 

It  is  useful  to  have  a  measure  of  how  deep  a  particular  class  is  in  the  hierarchy  so  that  the  class  can 
be  designed  with  reuse  of  inherited  methods. 

Metric  3:  Number  of  children  (NOC) 

Definition: 

NOC  =  number  of  immediate  sub-classes  subordinated  to  a  class  in  the  class  hierarchy. 

Theoretical  basis: 

NOC  relates  to  the  notion  of  scope  of  properties.  It  is  a  measure  of  how  many  sub-classes  are 

going  to  inherit  the  methods  of  the  parent  class. 

Viewpoints: 

Generally  it  is  better  to  have  depth  than  breadth  in  the  class  hierarchy,  since  it  promotes  reuse  of 

methods  through  inheritance. 

It  is  not  good  practice  for  all  classes  to  have  a  standard  number  of  sub-classes.  Classes  higher  up 
in  the  hierarchy  should  have  more  sub-classes  than  classes  lower  in  the  hierarchy. 

The  number  of  children  gives  an  idea  of  the  potential  influence  a  class  has  on  the  design.  If  a  class 
has  a  large  number  of  children,  it  may  require  more  testing  of  the  methods  in  that  class. 


Metric  4:   Coupling  between  objects  (CBO) 

Definition: 

CBO  for  a  class  is  a  count  of  the  number  of  non-inheritance  related  couples  with  other  classes. 

Theoretical  basis: 

CBO  relates  to  the  notion  that  an  object  is  coupled  to  another  object  if  two  objects  act  upon  each 

other,  i.e.,  methods  of  one  use  methods  or  instance  variables  of  another.  This  is  consistent  with 

traditional  definitions  of  coupling  as  "measure  of  the  degree  of  interdependence  between  modules" 

[Pressman,  1987]. 

Viewpoints: 

Excessive  coupling  between  objects  outside  of  the  inheritance  hierarchy  is  detrimental  to  modular 

design  and  prevents  reuse.  The  more  independent  an  object  is,  the  easier  it  is  to  reuse  it  in  another 

application. 

Coupling  is  not  associative,  i.e.,  if  A  is  coupled  to  B  and  B  is  coupled  to  C,  this  does  not  imply 
that  C  is  coupled  to  A. 

In  order  to  improve  modularity  and  promote  encapsulation,  inter-object  couples  should  be  kept  to  a 
minimum.  The  larger  the  number  of  couples,  the  higher  the  sensitivity  to  changes  in  other  parts  of 
the  design  and  therefore  maintenance  is  more  difficult 

A  measure  of  coupling  is  useful  to  determine  how  complex  the  testing  of  various  parts  of  a  design 
are  likely  to  be.  The  higher  the  inter-object  coupling,  the  more  rigorous  the  testing  needs  to  be. 

Metric  5:  Response  For  a  Class  (RFC) 

Definition: 

RFC  =  I  RS  I  where  RS  is  the  response  set  for  the  class. 

Theoretical  basis: 

The  response  set  for  the  class  can  be  expressed  as: 

RS  =  {Mi}  UaiinlRi) 
where  Mj  =  all  methods  in  the  class 
and  {  Ri )  =  set  of  methods  called  by  Mi 
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The  response  set  is  a  set  of  methods  available  to  the  object  and  its  cardinality  is  a  measure  of  the 
attributes  of  an  object.  Since  it  specifically  includes  methods  called  from  outside  the  object,  it  is 
also  a  measure  of  communication  between  objects. 

Viewpoints: 

If  a  large  number  of  methods  can  be  invoked  in  response  to  a  message,  the  testing  and  debugging 

of  the  object  becomes  more  complicated. 

The  larger  the  number  of  methods  that  can  be  invoked  from  an  object,  the  greater  the  complexity  of 
the  objecL 

The  larger  the  number  of  possible  methods  that  can  be  invoked  from  outside  the  class,  greater  the 
level  of  understanding  required  on  the  part  of  the  tester. 

A  worst  case  value  for  possible  responses  will  assist  in  appropriate  allocation  of  testing  dime. 

Metric  6:  Lack  of  Cohesion  in  Methods  (LCOM) 

Definition: 

Consider  a  Qass  Cj  with  methods  Mj,  M2... ,  M^.  Let  (li)  =  set  of  instance  variables  used  by 

method  M[.  There  are  n  such  sets  (Ij),...  {In). 

LCOM  =  The  number  of  disjoint  sets  formed  by  the  intersection  of  the  n  sets. 

Theoretical  basis: 

This  uses  the  notion  of  degree  of  similarity  of  methods.  The  degree  of  similarity  for  the  methods 

in  class  C^  is  given  by: 

o()  =  {Ii}n{l2}...n{In) 

If  there  are  no  common  instance  variables,  the  degree  of  similarity  is  zero.  However,  this  does  not 
distinguish  between  the  case  where  each  of  the  methods  operates  on  unique  sets  of  instance 
variables  and  the  case  where  only  one  method  operates  on  a  unique  set  of  variables.  The  number 
of  disjoint  sets  provides  a  measure  for  the  disparate  nature  of  methods  in  the  class.  Fewer  disjoint 
sets  implies  greater  similarity  of  methods.  LCOM  is  intimately  tied  to  the  instance  variables  and 
methods  of  an  object,  and  therefore  is  a  measure  of  the  attributes  of  an  object 
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Viewpoints: 

Cohesiveness  of  methods  within  a  class  is  desirable,  since  it  promotes  encapsulation  of  objects. 

Lack  of  cohesion  implies  classes  should  probably  be  split  into  two  or  more  sub-classes. 

Any  measure  of  disparateness  of  methods  helps  identify  flaws  in  the  design  of  classes. 

Low  cohesion  increases  complexity,  thereby  increasing  the  likelihood  of  errors  during  the 
development  process. 

Summary 

The  table  below  summarizes  the  six  metrics  in  relation  to  the  elements  of  OOD  shown  in  figure  L 


Metric 

Object  Definition 

Object  Attributes 

Object 
Communication 

WMC 

• 

• 

DIT 

• 

NOC 

• 

RFC 

• 

• 

CBO 

• 

LCOM 

• 

Table  1:  Mapping  of  Metrics  to  OOD  Elements 


rv.  METRICS  EVALUATION  PROPERTY  LIST 

Weyuker  has  developed  a  list  of  desiderata  for  software  metrics,  and  has  evaluated  a  number  of 
existing  software  metrics  using  these  properties  [Weyuker,  1988].  These  properties  are  repeated 
below. 

Property  1 :  Non-coarseness 

Given  an  object  P  and  a  metric  \i  another  object  Q  can  always  be  found  such  that: 
^(P)  ^  ^i  (Q). 
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This  implies  that  every  object  cannot  have  the  same  value  for  a  metric,  otherwise  it  has  lost  its 
value  as  a  measurement. 

Property  2:  Non-umqueness  (notion  of  equivalence) 

There  can  exist  distinct  objects  P  and  Q  such  that  )i  (P)  =  ^(Q).  This  implies  that  two  objects  can 
have  the  same  metric  value,  i.e.  the  two  objects  are  equally  complex. 

Property  3:  Permutation  is  significant 

There  exist  objects  P  and  Q  such  that  if  P  is  a  permutation  of  Q  (i.e.,  elements  in  P  are  simply  a 

different  ordering  of  the  elements  of  Q)  then  \x(P)  ^  (i(Q). 

Property  4:  Implementation  not  function  is  important 

Suppose  there  are  two  object  designs  P  and  Q  which  perform  the  same  function,  this  does  not 
imply  that  (i(P)  =  ^(Q).  The  intuition  behind  Property  4  is  that  even  though  two  object  designs 
perform  the  same  function,  the  details  of  the  implementation  matter  in  determining  the  object 
design's  metric. 

Prcoerty  5:  Monotoniciry 

For  all  objects  P  and  Q,  the  following  must  hold: 

^(P)  <  \xi?+Q) 

[i(Q)  <  [i(P+Q) 

where  P  +  Q  implies  concatenation  of  P  and  Q.  This  implies  that  objects  are  minimally  zero,  and 

therefore  that  the  combination  of  two  objects  can  never  be  less  than  either  of  the  component 

objects. 

Property  6:  Non-equivalence  ofinieracdon 

Given  3  P,  3  Q,  3  R, 

ji(P)  =  n(Q)  does  not  imply  that  ^t(P+R)  =  ^(Q+R). 

This  implies  that  interaction  between  P  and  R  can  be  different  than  interaction  between  Q  and  R. 

Property  7:  Interaction  increases  complexity 

3  P  and  Q  such  that: 

^i(  P)  +  n(Q)  <  ^i(  P+Q) 

The  idea  is  that  interaction  between  objeas  will  tend  to  increase  complexity. 

V.  RESULTS:  PROPERTIES  OF  THE  CANDIDATE  METRICS 
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A  design  goal  for  all  six  metrics  is  their  use  in  analysis  of  object  oriented  designs  independent  of 
the  programming  language. in  which  the  application  is  written.  However,  there  are  some  basic 
assumptions  made  regarding  the  distribution  of  objects,  methods  and  instance  variables  in  the 
discussions  for  each  of  the  metric  properties. 

Assumprion  1: 

Let    Xi  =  The  number  of  methods  in  a  given  class  i. 

Yi  =  The  number  of  methods  called  from  a  given  method  /. 

Z[  =  The  number  of  instance  variables  used  by  a  method  /. 

Ci  =  The  number  of  couplings  between  a  given  object  i  and  all  other  objects. 

Xj,  Yi,  Zi,  Ci  are  discrete  random  variables  each  characterized  by  some  general  distribution 

function.  Further,  all  the  Xis  are  independent  and  identically  distributed.  The  same  is  true  for  all 

the  Yis,  Zjs  and  Qs. 

Assumprion  2:  Xi  >  1  i.e.,  each  class  contains  one  or  more  methods. 

Assumption  3:  Two  classes  can  have  identical  methods,  in  the  sense  that  combination  of  the  two 

classes  into  one  class  would  result  in  one  of  the  methods  being  redundant. 

Assumprion  4:  The  inheritance  tree  is  "full"  i.e.,  there  is  a  root,  several  intermediate  nodes  which 

have  siblings,  and  leaves.  The  tree  is  not  balanced,  i.e.,  each  node  does  not  necessarily  have  the 

same  number  of  children. 

These  assimiptions  while  believed  to  be  reasonable,  are  of  course  subject  to  future  empirical  test. 

Metric  1:    Weighted  Methods  Per  Class  (WMC) 

Let  Xp  =  number  of  methods  in  class  P  and  Xn  =  number  of  methods  in  class  Q. 
Let  y  =  probability  Xp  ?t  Xq  ,  and  (1  -  y)  =  probability  Xp  =  Xq 

As  0  <  P  <  1  from  assumption  1,  there  is  a  fmite  probability  that  3  a  Q  such  that  |i(P)  ^  M-(Q), 
therefore  property  1  is  satisfied.  Similarly,  0  <  1  -  y  <  1,  there  is  a  finite  probability  tiiat  3  a  Q 
such  that  |i(P)  =  |i(Q).  Therefore  property  2  is  satisfied.  Permutation  of  elements  inside  the  object 
does  not  alter  the  number  of  methods  of  the  object.  Therefore  Propeny  3  is  not  satisfied.  The 
function  of  the  object  does  not  define  the  number  of  methods  in  a  class.  The  choice  of  methods  is 
an  implementation  decision,  therefore  Property  4  is  satisfied. 

Let  ^i(P)  =  np  and  |i(Q)  =  nq,  then  ^i(P+Q)  =  np  +  nq.  Clearly,  ^(P+Q)  >  |i(P)  and  ^(P+Q)  ^ 
|i(Q),  thereby  satisfying  property  5.  Now,  let  ji(P)  =  n,  \i(Q)  =  n,  3  an  object  R  such  that  it  has  a 
number  of  methods  9  in  common  with  Q  but  no  methods  in  common  with  P.  Let  p.(R)  =  r. 
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(I(P+R)  =  n  +  r 

|i(Q+R)  =  n  +  T-d 

therefore  ^(P+Q)  *  p.(Q+R)  and  property  6  is  satisfied.  For  any  two  objects  P  and  Q,  |J.(P+Q)  = 

"p  +  nq  -  d,  where  np  is  the  number  of  methods  in  P,  nq  is  number  of  methods  in  Q  and  P  and  Q 

have  B  methods  in  common. 
Clearly,  np  +  nq  -  9  <  np  +  nq  for  all  P  and  Q. 
i.e.,  |i(P+Q)  <  \i(P)  +  [i{Q)  for  all  P  and  Q. 
Therefore  Property  7  is  not  satisfied. 

Metric  2:  Depth  of  Inheritance  Tree  (DIT) 

Per  assumption  4,  every  tree  has  a  root  and  leaves.  The  depth  of  inheritance  of  a  leaf  is  always 
greater  than  the  root.  Therefore,  property  1  is  satisfied.  Also,  since  every  tree  has  at  least  some 
nodes  with  siblings,  there  will  always  exist  at  least  two  objects  with  the  same  depth  of  inheritance, 
i.e.,  property  2  is  satisfied.  Permutation  of  the  elements  within  an  object  does  not  alter  the  position 
of  the  object  in  the  inheritance  tree,  and  therefore  property  3  is  not  satisfied.  Implementation  of  an 
object  involves  choosing  what  properties  the  object  must  inherit  in  order  to  perform  its  function. 
In  other  words,  depth  of  inheritance  is  implementation  dependent,  and  property  4  is  satisfied 

When  any  two  objects  P  &  Q  are  combined,  there  are  three  possible  cases: 
i)  when  one  is  a  child  of  the  other 


In  this  case,  ^(P)  =  n,  |i(Q)  =  n  +  1,  but  ^(P+Q)  =  n,  i.e.  ^(P+Q)  <  \i  (Q).  Property  5  is  not 
satisfied. 
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Case  ii)  P  &  Q  are  siblings 


In  this  case,  p.(P)  =  |i(Q)  =  n  and  |i(P+Q)  =  n,  i.e.  Property  5  is  satisfied. 


Case  iii)  P  &  Q  are  not  directly  connected. 


If  P+Q  moves  to  P's  location  in  the  tree,  Q  does  cannot  inherit  methods  from  C,  however  if  P+Q 
moves  to  Q's  location,  P  maintains  its  inheritance.  Therefore,  P+Q  will  be  in  Q's  old  location.  In 
this  case,  p.(P)  =  x,  p.(y)  and  y  >  x.  |i(P+Q)  =  y,  i.e.,  M.(P+Q)  >  ^(P)  and  p.(P+Q)  =  p.  (Q)  and 
property  5  is  satisfied.  Since  ^i(P+Q)  >  |i(P)  is  not  satisfied  for  all  possible  cases,  Property  5  is 
not  satisfied.  Let  P  and  Q  be  siblings,  i.e.  n(P)  =  |i(Q)=  n,  and  let  R  be  a  child  of  P.  Then 
)i(P+R)  =  n  and  |i(Q+R)  =  n  +  1.  i.e.  |i(P+R)  is  not  equal  to  ^(Q+R).  Property  6  is  satisfied. 
For  any  two  objects  P  &  Q,  p.  (  P+  Q)  =  ^(P)  or  =  n(Q).  Therefore,  ^i(P+Q)  <  ^i(P)  +  [i{Q)  i.e. 
Property  7  is  not  satisfied. 
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Metric  3:  Number  Of  Children  (NOC) 

Let  P  and  R  be  leaves,  ^(P)  =  ^(R)  =  0,  let  Q  be  the  root  |i(Q)    >  0.    |i(P)  ^  p.(Q)  therefore 

property  1  is  satisfied.  Since  |i(R)  =  |J.(P),  Property  2  is  also  satisfied.  Permutation  of  elements 

within  an  object  does  not  change  the  number  of  children  of  that  object,  therefore  Property  3  is  not 

satisfied.   Implementation  of  an  object  involves  decisions  on  the  scope  of  the  methods  declared 

within  the  object,   i.e,  the  sub-classing  for  the  object.   The  number  of  sub-classes  is  therefore 

dependent  upon  implementation  of  the  object.  Therefore,  property  4  is  satisfied.  Let  P  and  Q  be 

two  objects  with  np  and  nq  sub-classes  respectively  (i.e.,  |J.(P)  =  np  and  |i(Q)  =  nq).     Combining 

P  and  Q,  will  yield  a  single  object  with  np  -i-  nq  -  8  sub-classes,  where  d  is  the  number  of  children 

P  and  Q  have  in  common.  Clearly,  3  is  0  if  either  np  or  nq  is  0.  Now,  np  -i-  nq  -  9  >  np  and  np  + 

nq  -3  >  nq.  This  can  be  written  as: 

^i(P-K^  >  ^i(P)  and  \i(?+Q)  >  ^(Q)  for  all  P  and  all  Q. 

Therefore,  Property  5  is  satisfied.  Let  P  and  Q  each  have  n  children  and  R  be  a  child  of  P  which 

has  r  children.  }i(P)  =  n  =  |J.(Q).  The  object  obtained  by  combining  P  and  R  will  have  (n-1)  +  r 

children,  whereas  an  object  obtained  by  combining  Q  and  R  will  have  n  +  r  children,  which  means 

that  ^(P-i-R)  ^  li(Q-i-R).  Therefore  property  6  is  satisfied. 

Given  any  two  objects  P  and  Q  with  np  and  nq  children  respectively,  the  following  relationship 

holds: 

^(P)  =  np  and  ^i(Q)  =  nq. 

^i(P+Q)  =  np  +  nq  -  3 

where  d  is  the  number  of  common  children. 

Therefore,  |i(P-M5)  <  |i(P)  -f-  |i(Q)  for  all  P  and  Q.  Property  7  is  not  satisfied. 

Metric  4:  Response  for  a  Class  (RFC) 

Let  Xp  =  RFC  for  class  P 
Xq  =  RFC  for  class  Q. 
Let  y  =  probability  Xp  ?t  Xq  ,  (1  -  y)  =  probability  Xp  =  Xq 

Xp  =  F(Yi)  and  Xq  =  F(Yj)  i.e.,  Xp  is  some  function  of  the  number  of  methods  called  by  a 
method  in  class  P.  Now,  FQ  is  monotonic  in  Y,  since  the  response  set  can  only  increase  as  the 
number  of  methods  called  increases.  Yj  and  Yj  are  independent  identically  distributed  discrete 
random  variables,  as  per  assumption  1.  Therefore,  F(Yi)  and  F(Yj)  are  also  discrete  random 
variables  that  are  i.i.d.  Therefore,  there  is  a  fmite  probability  that  3  a  Q  such  that  p.(P)  #  |i(Q) 
resulting  in  property  1  being  satisfied.  Also  as  0  <  1  -  y  <  1  there  is  a  finite  probability  that  3  a  Q 
such  that  ^(P)  =  ^1(0),  therefore  property  2  is  satisfied.  Permutation  of  elements  within  an  object 
does  not  change  the  number  of  methods  called  by  that  object,  and  therefore  property  3  is  not 
satisfied.  Implementation  of  an  object  involves  decision  about  the  methods  that  need  to  be  called 
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and  therefore  Propeny  4  is  satisfied.  Let  P  and  Q  be  two  classes  with  RFC  of  P  =  nn  and  RFC  of 
Q  =  nq.  If  these  rwo  classes  are  combined  to  form  one  class,  the  response  for  that  class  will  be  the 
larger  of  the  two  RFC  values  for  P  and  Q  =*■  |i  (P+Q)  =  Max(np,  nq).  Clearly,  Max(np,nq)  >  nn 
and  Max(np,nq)  >  nq  for  all  possible  P  and  Q.  |i(P+Q)  >  ^(P)  and  >  |i(Q)  for  all  P  and  Q. 
Therefore,  property  5  is  satisfied.  Let  P,  Q  and  R  be  three  classes  such  that,  |i(P)  =  [i(Q)  =  n  and 
|i(R)  =  r.  Then  |i(P+Q)  =  Max(n,r)  and  |i(Q+R)  +  MaxCn^").  i.e.,  [i(P+Q)  =  ^i(R+Q).  Therefore 
property  6  is  not  satisfied.  For  any  two  classes  P  and  Q,  |i(P+Q)  =  Max(p.(P),  |i(Q)).  Qearly, 
Max(|i(P),  |i(Q))  <  fi(P)  +  |i(Q)  which  means  that  Property  7  is  not  satisfied. 

Metric  5:  Lack  Of  Cohesion  Of  Methods  (LCOM) 

Let  Xp  =  LCOM  for  class  P 
Xq  =  LCOM  for  class  Q. 
Let  y  =  probability  Xp  ?i  Xq  ,  (1  -  y)  =  probability  Xp  =  Xq 

Xp  =  F(Yi)  and  Xq  =  F(Yj)  i.e.,  Xp  is  some  function  of  the  number  of  instance  variables  used  by 
a  method  in  class  P.  Now,  F()  is  monotonic  in  Y,  since  the  LCOM  can  only  decrease  as  the 
number  of  instance  variables  used  increases.  Yj  and  Yj  are  independent  identically  distributed 
discrete  random  variables,  as  per  assumption  1.  Therefore,  F(Yi)  and  F(Yj)  arc  also  discrete 
random  variables  that  are  i.i.d.  therefore  property  1  is  satisfied.  Also  asO<l-y<l.  then  there 
is  a  finite  probability  that  3  a  Q  such  that  |i(P)  =  |i(Q),  therefore  property  2  is  satisfied. 
Permutation  of  the  elements  of  an  object  does  not  alter  the  set  of  methods  called  from  that  object, 
consequently  not  changing  the  value  of  LCOM.  Therefore,  property  3  is  not  satisfied.  The  LCOM 
value  depends  on  the  construction  of  methods,  which  is  implementation  dependent,  making  LCOM 
also  implementation  dependent  and  satisfying  property  4.  Let  P  and  Q  be  any  two  objects  with 
p.(P)  =  Hp  and  p,(Q)  =  nq.  Combining  these  two  objects  can  potentially  reduce  the  number  of 
disjoint  sets,  i.e.,  |i(P+Q)  =  np  +  nq  -  9  where  9  is  the  number  of  disjoint  sets  reduced  due  to  the 
combination  of  P  and  Q.  The  reduction  9  is  some  function  of  the  particular  sets  of  instance 
variables  of  the  two  objects  P  and  Q.  Now,  np  >  9  and  nq  >  9  since  the  reduction  in  sets 
obviously  cannot  be  greater  than  the  number  of  original  sets.  Therefore,  the  following  result 
holds: 

np  +  nq  -9  >  np   for  all  P  and  Q  and 
np  +  nq  -  9  >  nq  for  all  P  and  Q. 
Property  5  is  satisfied. 

Let  P  and  Q  be  two  objects  such  that  p.(P)  =  |J.(Q)  =  n  ,  and  let  R  be  another  object  with  )i(R)  =  r. 
|i(P+Q)  =  n  +  r  -  9,  similarly 
[iCQ+R)  =  n  +  r  -  B 
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Given  thai  d  and  B  are  not  functions  ot"  n,  they  need  not  be  equal,    i.e.,  ti(P+R)  ^  |i(Q+R), 
satisfying  propeny  6.  For  any  two  objects  P  and  Q,  |i(P+Q)  =  np  +  nq  -  8.  i.e., 
}I(P+Q)  =  |i(P)  +  |i(Q)  -  3  which  implies  that 
^i(P+Q)  <  ^l(P)  +  |I(Q)  for  all  P  and  Q. 
Therefore  property  7  is  not  satisfied. 

Metric  6:  Coupling  Between  Objects  (CBO) 

As  per  assumption  1,  there  exist  objects  P,  Q  and  R  such  that  |J.(P)  ^  |i(Q)  and  |l(P)  =  ^(R) 
satisfying  properties  1  and  2.  Permutation  of  the  elements  inside  an  object  does  not  change  the 
number  of  inter-object  couples,  therefore  property  3  is  not  satisfied.  Inter-object  coupling  occurs 
when  methods  of  one  object  use  methods  or  instance  variables  of  another  object,  i.e.,  coupling 
depends  on  the  construction  of  methods.  Therefore  property  4  is  satisfied.  Let  P  and  Q  be  any 
two  objects  with  }i(P)  =  np  and  |i(Q)  =  nn.  If  P  and  Q  are  combined,  the  resulting  object  will  have 
np  +  nq  -  3  couples,  where  3  is  the  number  of  couples  reduced  due  to  the  combination.  That  is 
M-(P+Q)  =  np  -t-  nq  -  3,  where  3  is  some  function  of  the  methods  of  P  and  Q.  Clearly,  np  -  3  >  0 
and  nq  -  3  >  0  since  ±e  reduction  in  couples  cannot  be  greater  than  the  original  number  of  couples. 

Therefore, 

np  +  nq  -  3  >  np  for  all  P  and  Q  and 

np  +  nq-3^nqforallP  and  Q 

i.e.,  }i(P+Q)  >  li(P)  and  |i(P+Q)  >  ^i(Q)  for  all  P  and  Q.  Thus,  property  5  is  satisfied.  Let  P  and 

Q  be  two  objects  such  that  ^(P)  =  |i(Q)  =  n  ,  and  let  R  be  another  object  with  p,(R)  =  r. 

p,(P-HQ)  =  n  -I-  r  -  3,  similarly 

^(Q-i-R)  =  n  +  r  -  6 

Given  that  3  and  B  are  not  functions  of  n,  they  need  not  be  equal,  i.e.,  |i(P+R)  is  not  equal  to 

}i(Q+R),  satisfying  property  6.  For  any  two  objects  P  and  Q,  li(P+Q)  =  np  +  nq  -  3. 

^i(P+Q)  =  |i(P)  +  ^1(0)  -  3  which  implies  that 

^(P+Q)  <  ^i(P)  +  ^t(Q)  for  all  P  and  Q. 

Therefore  property  7  is  not  satisfied. 

Summary  of  results 

All  six  metrics  fail  to  meet  property  3,  suggesting  that  perhaps  permutation  of  elements  within  an 
object  is  not  significant.  The  intuition  behind  this  is  that  measurements  on  class  design  should  not 
depend  on  ordering  of  elements  within  it,  unlike  program  bodies  where  permutation  of  elements 
should  yield  different  measurements  reflecting  the  nesting  of  if-then-else  blocks. 
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The  rarionaJe  behind  propeny  7  according  to  Weyuker  is  to  "aJlow  for  the  possibility  of  increased 
complexity  due  to  potential  interaction"  [Weyiiker,  1988].  All  six  metrics  fail  to  meet  this, 
suggesting  that  perhaps  this  is  not  applicable  to  object  oriented  designs.  This  also  raises  the  issue 
that  complexity  could  increase,  not  reduce  as  a  design  is  broken  into  more  objects.  Further 
research  in  this  area  is  needed  to  clarify  this  issue. 

The  RFC  metric  fails  to  satisfy  property  6  and  the  DIT  metric  fails  to  satisfy  property  5.  These 
deficiencies  are  a  result  of  the  definition  of  the  two  metrics  and  further  refinements  will  be  required 
to  satisfy  these  properties.  It  is  worth  pointing  out  that  Harrison  [1988]  and  Zuse  [1991]  have 
criticized  the  non-equivalence  of  interaction  property  (property  6)  and  note  that  this  property  may 
not  be  widely  applicable.  Also,  the  DIT  metric,  as  shown  earlier  does  not  satisfy  the  monotonicity 
property  (property  5)  only  in  the  case  of  combining  two  objects  in  different  parts  of  the  tree,  which 
empirical  research  may  demonstrate  to  be  a  rare  occurrence.  Table  2  presents  a  summary  of  the 
metrics  properties. 

Summary  of  Results 


METRIC 

PI 

P2 

P3 

P4 

P5 

P6 

P7 

WMC 

Yes 

Yes 

NO 

Yes 

Yes 

Yes 

NO 

DIT 

Yes 

Yes 

NO 

Yes 

NO 

Yes 

NO 

NOC 

Yes 

Yes 

NO 

Yes 

Yes 

Yes 

NO 

RFC 

Yes 

Yes 

NO 

Yes 

Yes 

NO 

NO 

LCOM 

Yes 

Yes 

NO 

Yes 

Yes 

Yes 

NO 

CBO 

Yes 

Yes 

NO 

Yes 

Yes 

Yes 

NO 

Table  2:  Summary  of  Metrics  Properties 


VI.  CONCLUDING  REMARKS 

This  research  has  developed  a  new  set  of  software  metrics  for  00  design.  These  metrics  are  based 
in  measurement  theory,  and  also  reflect  the  viewpoints  of  experienced  OO  software  developers.  In 
evaluating  these  metrics  against  a  set  of  standard  criteria,  they  are  found  to  both  (a)  perform 
relatively  well,  and  (b)  suggest  some  ways  in  which  the  00  approach  may  differ  in  terms  of 
desirable  or  necessary  design  features  from  more  traditional  approaches.   Clearly  some  future 
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research  designed  both  to  extend  the  current  proposed  memc  set  and  to  further  investigate  these 
apparent  differences  seems  warranted. 

In  particular,  this  set  of  six  proposed  metrics  is  presented  as  a  frrst  attempt  at  development  of 
formal  metrics  for  OOD.  They  are  unlikely  to  be  comprehensive,  and  further  work  could  result  in 
additions,  changes  and  possible  deletions  from  this  suite.  However,  at  a  minimum,  this  proposal 
should  lay  the  groundwork  for  a  formal  language  with  which  to  describe  metrics  for  OOD.  In 
addition,  these  metrics  may  also  serve  as  a  generalized  solution  for  other  researchers  to  rely  on 
when  seeking  to  develop  specialized  metrics  for  particular  purposes  or  customized  environments. 

Currently  planned  empirical  research  will  aaempt  to  validate  these  candidate  metrics  by  measuring 
them  on  actual  systems.  In  particular,  a  three-phased  approach  is  planned  In  Phase  I,  the  metrics 
will  be  measured  on  a  single  pilot  system.  After  this  pilot  test.  Phase  n  will  consist  of  calculating 
the  metrics  for  multiple  systems  and  simultaneously  collecting  some  previously  established  metrics 
for  purposes  of  comparison.  These  previously  existing  metrics  could  include  such  well-known 
measures  as  source  hnes  of  code,  function  points,  cyclomatic  complexity,  software  science 
metrics,  and  fan-in/fan-out.  Finally,  Phase  HI  of  the  research  will  involve  collecting  performance 
data  on  multiple  projects  in  order  to  determine  the  relative  efficacy  of  these  metrics  in  predicting 
managerially  relevant  performance  indicators. 

It  is  often  noted  that  00  may  hold  some  of  the  solutions  to  the  software  crisis.  Further  research  in 
moving  00  development  management  towards  a  strong  theoretical  base  should  provide  a  basis  for 
significant  future  progress. 
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